Path O-RAM: 
An Extremely Simple Oblivious RAM Protocol 



Emil Stefanov Elaine Shi 

UC Berkeley UC Berkeley 

emil@ cs . berkeley. edu elaines® cs .berkeley.edu 



Abstract 

We present Path O-RAM, an extremely simple Oblivious RAM protocol. 



1 Introduction 

In this technical report, we present an extremely simple construction for Oblivious RAM with 
low-bandwidth overhead. We call our protocol Path O-RAM. 



2 Related Work 

Oblivious RAM was first investigated by Goldreich and Ostrovsky |4|[5|[Toj in the context of pro- 
tecting software from piracy, and efficient simulation of programs on oblivious RAMs. Since then, 
there has been much subsequent work [l}|3|[6]-(9| [IT}jl5] . 



3 Problem Definition 
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Figure 1: Oblivious RAM scenario. 



We consider a client that wishes to store data at a remote untrusted server while preserving its 
privacy (depicted in Figure [TJ . While traditional encryption schemes can provide confidentiality, 
they do not hide the data access pattern which can reveal very sensitive information to the untrusted 
server. In other words, the blocks accessed on the server and the order in which they were accessed 
is revealed. We assume that the server is untrusted, and the client is trusted, including the client's 
processor, memory, and disk. 
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The goal of 0-RAM is to completely hide the data access pattern (which blocks were read/written) 
from the server. From the server's perspective, read/write operations are indistinguishable from 
random requests. 

Notations. We assume that the client fetches/stores data on the server in atomic units, referred 
to as blocks, of size B bytes each. For example, a typical value for B for cloud storage is 64 KB to 
256 KB. Throughout the paper, we use the notation N to denote the capacity of the 0-RAM (i.e., 
the total number of data blocks that the 0-RAM can hold). 

Simplicity. Our construction is extremely simple in contrast with previous constructions. It 
consists of only 18 lines of pseudo-code as shown in Figure [2j 



Security definitions. We adopt the standard security definition for 0-RAMs from 14 . Intu- 
itively, the security definition requires that the server learns nothing about the access pattern. In 
other words, no information should be leaked about: 1) which data is being accessed; 2) how old it 
is (when it was last accessed); 3) whether the same data is being accessed (linkability); 4) access 
pattern (sequential, random, etc); or 5) whether the access is a read or a write. 

Definition 1 (Security definition). Let 

y := ((opi, ui, datai), (op2, U2, data2), . . . , (opjvj, ua/, dataA/)) 

denote a data request sequence of length M , where each opj denotes a read(ui) or a write(uj, data) 
operation. Specifically, Uj denotes the identifier of the block being read or written, and data^ denotes 
the data being written. 

Let A{y) denote the (possibly randomized) sequence of accesses to the remote storage given the 
sequence of data requests y. An 0-RAM construction is said to be secure if for any two data request 
sequences y and z of the same length, their access patterns A{y) and A[z) are computationally 
indistinguishable by anyone but the client. 

Like all other related work, our 0-RAM constructions do not consider information leakage 
through the timing channel, such as when or how frequently the client makes data requests. 



4 The Path O-RAM Protocol 

4.1 Overview 

We first give an overview of the Path 0-RAM protocol. The client stores a small amount of local 
data in a cache. The server-side storage is treated as a binary tree where each node is a bucket 
that can hold up to a fixed number of blocks. We maintain the invariant that at any time, each 
block is mapped to a uniformly random leaf bucket in the tree, and uncached blocks are always 
placed in some bucket along the path to the mapped leaf. Whenever a block is read from the server, 
the entire path to the mapped leaf is read into into the cache, the requested block is remapped to 
another leaf, and then the path is written back to the server. When the path is written back to 
the server, additional blocks in the cache may be evicted into the path as long as the invariant is 
preserved and there is remaining space in the buckets. 
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4.2 Server Storage 

Definition 2 (Tree). The server stores a binary tree data structure of height L and 2^ leafs. The 
tree can easily be laid out as a flat array. The levels of the tree are numbered to L where level 
denotes the root of the tree and level L denotes the leafs. 

Definition 3 (Bucket). Each node in the tree is called a bucket. Each bucket can contain up to Z 
blocks. If a bucket has less than Z real blocks, the remaining blocks are dummy blocks. The entire 
bucket is always stored as an encrypted fixed-size byte array, and hence the server can't distinguish 
between real and dummy blocks. 

In practice, we would choose Z to be a small number such as 3 or 4. 

4.3 Client Storage 

Definition 4 (Cache). At any point in time, the client stores a small subset of the N possible 
blocks into a data structure C called the cache. 

Definition 5 (Position map). The client stores a position map array position [u] that consists of N 
integers, mapping each block u to one of the 2^ leaf buckets in the server's tree data structure. The 
mapping is random and hence multiple blocks may be mapped to the same leaf and there may exist 
leafs to which no blocks are mapped. The position map changes over time as blocks are accessed 
and remapped. 

4.4 Initialization 

The client cache C is initially empty. The position map initially contains null for the position of 
every block. The position null is a special value indicating that the corresponding block has never 
been accessed and the client should assume it has a default value of zero. 

4.5 Reads and Writes 

Definition 6 (Path). The path V{p) is the set of identifiers of tree buckets along the path from the 
root of the tree to the leaf bucket with index p. V{p,£) is the identifier for the bucket in P{p) at 
level a. in the tree. 

The protocol for reading/writing a block is described in Figure [2] The algorithm can be sum- 
marized in four simple steps: 

1. Remap. Randomly remap the position of block u. (Lines 1 to 2) 

2. Read. Read the path containing block u. (Lines 3 to 5) 

3. Update. If the access is a write, update the data stored for block u. (Lines 6 to 11) 

4. Write. Write the path back and possibly include some additional blocks from the cache. 
(Lines 12 to 17) 

If the special case that the requested block has a position of null (i.e., it has never been read 
before), the client should access a random path and place a zero block in the 0-RAM for the 
corresponding position. 
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Access(op, u, data*): 


1 


p <r- position[u] 


2 


position[u] ^ UniformRandom(0 ... 2^ — 1) 


3 


for £ e {0, 1, . . . , L} do 


4 


C ^ C U ReadBucket(P(p, £)) 


5 


end for 


6 


data data' for which (u,data') G C 


7 


if op = write then 


8 


C ^ C - {(u,data)} 


9 


data i — data* 


10 


C ^ CU{(u,data)} 


11 


end if 


12 


for £ G {L,L - 1, ... ,0} do 


13 


S ^ {(u', data') E C : V{p, i) = P(position[u'], ^)} 


14 


Remove min( 5* , Z) random blocks from S. 


15 


C ^C-S 


16 


WriteBucket(P(p,^),S') 


17 


end for 


18 


return data 



Figure 2: Algorithm for data access. Read or write a data block identified by u. If op = read, 
the input parameter data* = None, and the Access operation returns the newly fetched block. If 
op = write, the Access operation writes the specified data* to the block identified by u. 

5 Extensions 
5.1 Integrity 

Our protocol can be easily extended to provide integrity (with freshness) for every access to the 
untrusted storage. Because data from untrusted storage is always fetched and stored in the form 
of a tree path, we can extend the tree data structure stored on the server to become a Merkle tree. 
Hence the client only needs to store a single hash of the Merkle tree root in order to verify the 
integrity and freshness of any path. 

6 Experiments 

We conducted experiments to measure the size of the client's cache for different bucket sizes and 
number of levels. Figures [3] and |4] show the results. 
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Max Cache Size for 3N Operations, I = log2 ^ - 1 




4 6 8 10 12 14 16 18 20 22 



Figure 3: Client cache size for different bucket sizes (denoted as Z). 
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Figure 4: Client cache size for a different number of levels in the tree (denoted as L). 
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